Hi Ron,

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Thursday, March 27, 2014 12:09 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; sfc@ietf.org
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Regarding the SF Index, draft-zhang-sfc-sch defines this as relative to the path, and not as a globally unique identifier of an SF instance.
[Lucy] This is my understanding too. ¡°The path¡± here means a SFC, right? I do not see index as an SF instance identifier at all, it is an alias and only used in forwarding. This is the reason, I think, that assigning these aliases and configuring then in forwarding table is complex for management and controller and may prune an error easily. For supporting bi-directional or branching use cases, using index in forwarding may also bring other concerns.

Regarding TTL, my first thought is that is a property of the transport, and if it is important to you, choose the transport accordingly.   But, I¡¯m open to further discussion along these lines.
[Lucy] Thank you for the clarification. This is related to the discussion under this title. If SPC is implemented as IP or IP/UDP application, it can leverage a lot what IP technology have done. If we assume that SFC may be carried over any transport solution, SFC implementation has to provide these functions, which, IMO, related to what information that SFC header need to hold.

Thanks,
Lucy

   Ron


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Thursday, March 27, 2014 12:26 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

I assume that the index usage you mentioned below is the same whether these three SFs are on one SFF or two SFFs, which means that the index # is assigned to SF-X-I per SFC and by the incremental. A SF-X-I may be served to many SFCs and position differently in SFCs. This means that, in this method, a SF-X-I is mapped with different index #, one per each SFC that has the SF-X-I. IMO:  when operator/system creates a SFC and selects SF-X-Is for the SFC, and then assign index # to them and configure the forwarding table with path ID and index # in the related SFFs. Furthermore, each index # also need to be associated to the address or port that transport layer can understand.  IMO: this is a complex process for the system, uneasy to manger too, and may easily prone an error.

Second, your draft also mention that the use of index to prevent the loop.  The loop does not occur in normal condition. The loop occurs in abnormal condition. So the loop prevention mechanism is to prevent no loop happen in any abnormal condition. That is why TTL is designed for in IP network. If SFC header is expected to transport over any transport network beside IP, it needs the similar mechanism as IP/TTL. The usage of index in your proposal does not achieve this purpose.

If we use IP as transport, IMO: no need to implement TTL mechanism within SFC, just leverage IP TTL capability. But, if over other transports, we need to implement IP/TTL like mechanism in SFC.

Regards,
Lucy


From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Thursday, March 27, 2014 9:35 AM
To: Xuxiaohu; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Xiaohu,

I don¡¯t think we need to view the SF index as a TTL.   Appropriate validation and loop suppression can be done even with the current proposed definition.    Any SFF receiving an SFC encapsulated packet or frame would need to know to which of its dependent SF¡¯s it should forward the packet or frame.   To do so means that it can validate that the path ID is one that it expects to participate in and that the SF instance identified by the index on that path is one that it is responsible for.    Such chain path data may have been locally provisioned or may have been distributed in a control plane.

When the SFF receives the good packet or frame back from one of its dependent SF¡¯s, it will identify the next SF and SFF by consulting its local database.   If it is not the final SF, then the SF index is incremented, the transport header updated as necessary, and the packet or frame progressed.    Failure to properly increment the SF Index would be akin to failure to decrement a TTL by a router ¨C there is no protection from that.

   Ron


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, March 27, 2014 5:44 AM
To: Ron Parker; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?


·¢¼þÈË: sfc [mailto:sfc-bounces@ietf.org] ´ú±í Ron Parker
·¢ËÍʱ¼ä: 2014Äê3ÔÂ26ÈÕ 7:13
ÊÕ¼þÈË: Lucy yong; Reinaldo Penno (repenno); Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Ö÷Ìâ: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Regarding the service function index that would be contained in the service header, I think it is simply incremented from 1 to indicate the next service function within the chain.   For example, if the path ID is X, for a path {SF-A-5, SF-B-2, SF-C-6}, then packets destined from a classifier towards SF-A-5 would carry (path X, index 1), packets from SF-A-5 to SF-B-2 would carry (path X, index 2), etc.

[Xiaohu] I think the value of the service index should be decremented, rather than being incremented when travelling along the service path since that index is not only used for indicating the next service function within the chain, but also used for other purposes (e.g., TTL of the service path, indicator of the end of the service chain), unless you want to introduce an additional field which indicates the total length of the service chain.

Best regards,
Xiaohu

   Ron

________________________________
From: sfc [sfc-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.com]
Sent: Tuesday, March 25, 2014 6:38 PM
To: Reinaldo Penno (repenno); Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?
Hi Reinaldo,

Thank you to share your views on this solution. We want to have an elegant and general solution with one standard SFC header to cover majority use cases

See inline below.


From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Lucy yong; Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

There are several solution to this problem. Some of them implementation specific, others more elegant.

1 - One of the more elegant ones is to use the Service Index to determine the next service function instance.  It makes for a completely stateless solution (code wise).
[Lucy] when using Path ID and Service Index on SFC header, it requires assigning index # to each SF instance, configuring them in the forwarding table, which is very complex process and easily prune for error in may opinion.  In addition, each SF instance may serve more than one SFC, so need to assign index # for each SFC, which is more complex. Regarding the stateless, I don¡¯t get it. Isn¡¯t index # a state as well (may be few bit less)?

To implement true stateless, SFC header needs ability to carry all SFIs IP addresses in SFC header, which was considered as non-scale solution.


2 ¨C Another option is from a coding perspective you can just keep more state in your SN/SFF while you process the packet and determine what is the ¡°next¡± service.
[Lucy] Agree.

But irrespective, the SN needs to know the Path ID and the list of SFIs internal to its node. This provisioning can happen in a variety of ways, I implemented with RESTconf and Netconf.

As far as UDP/IP vs.IP, I give preference to UDP/IP. If you have a fixed port over UDP in which to receive/send packets:

- You can have your entire dataplane in userpace and use a variety of programming languages.
- You do not need raw packet access to pull/send packets. Therefore no root support.
- UDP can traverse non-SFC aware middlexboxes.
[Lucy] Agree on this statement. But for SFC domain, do we want to allow such midboxes on SFC path? Maybe happen if a SFC domain crosses more than transport domains? This is one I like to know from SPs and SF vendors.

Regards,
Lucy
Or you can use any of the available methods( TURN, STUN, etc).  If you encap in something else other than IP/UDP the applicability of SFC will be considerably diminished.Just check STCP and its problem on getting adopted given middlexboxes  not recognizing its protocol number.

- It jives with other IETF work in the areas of metadata and transport services (say, TAPS).

regards,

Reinaldo



From: Lucy yong <lucy.yong@huawei.com<mailto:lucy.yong@huawei.com>>
Date: Tuesday, March 25, 2014 at 2:25 PM
To: Dave Dolson <ddolson@sandvine.com<mailto:ddolson@sandvine.com>>, "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Dave,

If a service forwarder point connects more than one SF instances that belong to the same SFC, how can one Path ID determine which SF instances is the next? If you draw a service chain path with many SF instances, you can easily see, if Path ID represents that path, service forwarder needs to use previous SF on the path to position the next SF on that path.

Lucy

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, March 25, 2014 4:10 PM
To: Lucy yong; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: SFC as an IP or UDP application, pros and cons?

Why do you think the previous SF IP address is required to determine the next SF IP address? Why is the Path ID not sufficient information?


From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Dave Dolson; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: SFC as an IP or UDP application, pros and cons?

In this solution, service forwarder and SF instance are separated entities. Service forwarder needs Path ID and previous SF IP address to uniquely identify the next SF IP address.

Lucy

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Tuesday, March 25, 2014 3:21 PM
To: Lucy yong; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: SFC as an IP or UDP application, pros and cons?

I do not see why source IP address (previous SF) would be required to look up the next SF. The path ID should be sufficient to determine the next SF.





From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:02 PM
To: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

There are many ways to implement SFCs. However, one of our goals in standard is to develop a solution that is simple and less cost for venders and service providers.  Other goals are that the solution can apply to common and majority use cases.

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is classified by the classification, it adds SFC header and IP header (outer) on the packets (UDP header too in latter case), and send such packets as a regular IP packet. The src IP of outer header can be classification IP address, and dst IP can be next SF Instance IP address. Many transport networks can carry IP traffic and route IP packets based on dst IP address.  We only need to request a new IP protocol type for SFC. At the service forwarder point, it can look up next SF IP address based on Path ID in SFC header and src IP address (previous SF) on the packet.  A SF also forwards the packet with SFC header as an IP packet and fills its IP address as src IP and the service forwarder point IP address as the dst IP on the packet.

This solution works for either SFC as an IP application or UDP/IP application, which one is more proper from SF and service forwarder point?

This solution seems simple to me and only need Path ID in SFC header for steering traffic through the SFC path. But like to see others¡¯ opinion on this solution, pros and cons.

Thanks,
Lucy